Deployment Planning

This section focuses on the different decisions and information that must be known before the deployment of GigaVUE Cloud Suite for AWS. It assumes you have read the previous chapters and have a good understanding of the Cloud Suite components and concepts, along with AWS components, services, and architectures.

Refer to the following sections for more detailed information:

Identify the Deployment Method

GigaVUE Cloud Suite for AWS supports two options for deploying the Fabric Components:

In either scenario, GigaVUE-FM must first be launched and running. GigaVUE-FM may be deployed from the AWS Marketplace via a template or using script-based approach such as Cloud Formation, Terraform or other.

GigaVUE-FM Orchestration

In this method, the GigaVUE Fabric Components are deployed using the GigaVUE-FM user interface.  After launching GigaVUE-FM, and applying the required license, you can deploy GigaVUE V Series Node, GigaVUE V Series Proxy, and UCT-V Controller using the GigaVUE-FM interface. Once deployed, GigaVUE-FM monitors the state of the deployed fabric components, and automatically replaces or relaunches them if any error conditions occur.

The GigaVUE-FM Orchestrated option simplifies the GigaVUE Cloud Suite for AWS deployment in AWS but requires AWS API access and permissions to deploy and manage visibility fabric VMs.

Third Party Orchestration

In this method, the GigaVUE Fabric Components are deployed by an external process, typically a combination of Ansible and Terraform products or similar products.  You can also use AWS as your Orchestrator. All of the GigaVUE fabric component images are accessible in AWS to support this method.

The Third Party Orchestration method provides an automated method to deploy fabric components in AWS. In this case, GigaVUE-FM can operate with a reduced set of permissions, or with no AWS API access at all (depending on solution architecture). Refer to Architecturefor more details.

This method requires an additional configuration file for GigaVUE V Series Node, GigaVUE V Series Proxy, UCT-V Controller, and UCT-V to register with the Monitoring Domain created in GigaVUE-FM. However, you can use the GigaVUE-FM to monitor the fabric components health. But you cannot use GigaVUE-FM to replace or relaunch the externally deployed fabric components.

Identify the AWS Regions

GigaVUE Cloud Suite for AWS may be deployed such that a single GigaVUE-FM instance will manage and orchestrate the solution across multiple AWS regions. Each region will require its own Monitoring Domain and separate fabric components must be deployed. To avoid inter-region data transfers and associated costs, the fabric components (and tools) should be deployed in each region as best practice.

Define GigaVUE-FM Deployment Location

GigaVUE-FM may be deployed inside or outside of AWS, such as an existing GigaVUE-FM instance on-premises. While this option exists, deploying a new instance of GigaVUE-FM in AWS has the following benefits:

  1. To eliminate any upgrade requirements for existing on-premises GigaVUE-FM instance and GigaVUE appliances.
  2. To enable AWS Instance Role-based credentials and eliminate the need to create or configure AWS credentials in GigaVUE-FM, especially in multi-account deployments.
  3. As an alternative you can use AWS access keys for credentials if GigaVUE-FM is external to AWS.

Points to Note:

  • If GigaVUE-FM is deployed inside AWS, use IAM Role Based credentials.
  • If GigaVUE-FM is deployed outside AWS, use Access Keys.

Identify the Traffic Acquisition Method

GigaVUE Cloud Suite for AWS supports traffic acquisition that includes AWS VPC Traffic Mirroring (TM), Gigamon Universal Cloud Tap, and customer orchestrated sources.

The traffic acquisition variations supported are:

  • Direct VPC Traffic Mirroring
  • VPC Traffic Mirroring with Network Load Balancer
  • VPC Traffic Mirroring with Gateway Load Balancer
  • UCT-V for VMs
  • UCT-C for Containers
  • Customer Orchestrated Source
  • Customer Orchestrated Source with Gateway Load Balancer
  • Customer Orchestrated Source with Network Load Balancer
  • Inline V Series Solution

When creating a Monitoring Domain in GigaVUE-FM, you can choose any of the following Traffic Acquisition Methods:

  • VPC Traffic Mirroring
  • UCT-V
  • Customer Orchestrated Source
  • Inline

You can only choose one traffic acquisition method per Monitoring Domain. To use different traffic acquisition methods, you can create multiple Monitoring Domains. Currently, GigaVUE Cloud Suite for AWS does not support VPC Traffic Mirroring and UCT-V in the same Monitoring Domain.

GigaVUE Cloud Suite for AWS requires each Monitoring Domain and its fabric components to be deployed in a separate VPC.

Each Monitoring Domain supports one primary traffic acquisition type, but tunnel-based traffic sources can be added as overlays using tunnels in a Monitoring Session. This allows traffic from containers and third-party tunnel sources to be aggregated into the same Monitoring Domain, regardless of its primary acquisition type.

Identify the Deployment Model

GigaVUE Cloud Suite for AWS provides flexibility in terms of the deployment model and the deployment location of fabric components. The deployment model can be of three types:

  • Centralized
  • Distributed
  • Hybrid

Deployment Model for GigaVUE V Series Node

Centralized

In this model, the acquired traffic is forwarded or aggregated to a central location (central VPC), typically called the Tools VPC, where the GigaVUE V Series Node, load balancers (if used), and analysis tools are all colocated. This setup optimizes resource usage by centralizing traffic processing, enabling efficient scaling and simplified management. However, AWS costs may apply for traffic transfer via Transit Gateway (TGW) or Gateway Load Balancer (GWLB). Proper resource planning ensures the central VPC can handle the aggregated traffic effectively.

Distributed

In this model, GigaVUE V Series Nodes, UCT components (if used), and analysis tools are deployed directly into each VPC to process mirrored traffic locally. This approach minimizes data transfer costs by reducing reliance on Transit Gateway (TGW) or Gateway Load Balancer (GWLB) for traffic forwarding. While this requires additional EC2 resources in each VPC, it optimizes performance, lowers AWS costs, and ensures efficient local traffic processing and analysis.

Hybrid

In this model, a combination of both centralized and distributed deployment models is used. This hybrid approach allows for flexibility, where the design is optimized based on traffic volume, cost considerations, and performance needs. By considering factors like compute costs for GigaVUE V Series Nodes and GigaVUE V Series Proxy and the data transfer costs between VPCs, you can design a solution that balances efficiency and budget. For local traffic, a distributed model reduces transfer costs, while centralizing processing may simplify management but incur higher data transfer fees. The key is to tailor the design based on your specific needs.

Deployment Model for UCT-V Controller

For UCT-V traffic acquisition, at least one UCT-V Controller must be deployed to act as a communication proxy between GigaVUE-FM and the UCT-Vs. The UCT-V Controller connects to each UCT-V and maintains a single connection to GigaVUE-FM. Its placement can be optimized to localize traffic and simplify security groups or network firewall rules.

Centralized

The centralized UCT-V Controller model simplifies deployment but requires additional network connections between the UCT-V Controller and distributed UCT-V instances.

Distributed

The distributed UCT-V Controller model enhances communication efficiency by minimizing security group and firewall requirements between GigaVUE-FM and UCT-V Controller, while localizing connections to UCT-V instances. Its small VM footprint enables the cost-effective deployment of multiple controllers.

Hybrid

In this model, a combination of both centralized and distributed deployment models is used. It is common to combine centralized and distributed deployment models based on traffic, costs, and desired traffic types to optimize for cost and performance. Considerations should include computing costs for the controller VMs vs. the traffic crossing any VPC barrier.

Identify the AWS Accounts Involved

Most GigaVUE Cloud Suite for AWS deployments enable network visibility across multiple AWS accounts using AWS Secure Token Service (STS), Assumed Roles, and trust relationships. This eliminates the need to store credentials for different accounts in GigaVUE-FM.

Centralized vs Decentralized Account Deployment

When planning, identify all AWS accounts involved in the deployment:

Centralized Model

  • A single central account hosts the visibility fabric components, including GigaVUE-FM, UCT-V Controller, GigaVUE V Series Nodes, and tools.
  • Traffic sources reside in multiple VPCs across other AWS accounts.

Distributed Model

  • The GigaVUE fabric components are deployed across all involved accounts.
  • Clearly define the locations of deployed modules within each account.

Planning Action:

  • For the centralized model, define the central account and list all other accounts requiring traffic visibility.
  • For the distributed model, identify all accounts and specify where the modules will be deployed.

Identify the Subnets Involved

For each AWS Region, based on the chosen traffic acquisition method, identify the subnets involved.

For Traffic Mirroring and Customer Orchestrated Source

  • For Centralized GigaVUE V Series Node deployment model or if load balancer used:
    • Define the central VPC and subnet where GigaVUE V Series Nodes and load balancer (if used) will be deployed.
  • For the Distributed GigaVUE V Series Node deployment model:
    • Define the list of all VPCs and associated subnets where GigaVUE V Series Nodes will be deployed.
  • Make note if each each VPC or subnet is pre-existing or needs to be created.

For UCT-V

  • For the Centralized UCT-V Controller deployment model:
    • Define the central VPC and subnet where the UCT-V Controller will be deployed.
  • For the Distributed UCT-V Controller deployment model:
    • Define the list of all VPCs and associated subnets where UCT-V Controller instances will be deployed.
  • Make note if each each VPC or subnet is pre-existing or needs to be created.

For UCT-C

Define a list of EKS clusters that contain EC2 worker nodes where UCT-C components will be deployed. Refer to Universal Cloud TAP - Container Deployment Guide for more detailed information.

Identify the Required IAM Roles, Policies, and Permissions

GigaVUE-FM uses the AWS API to perform various tasks depending on the solution architecture. The IAM policy attached to the role used by GigaVUE-FM must contain the necessary permissions to perform those tasks. Refer to Permissions and Privileges (AWS) for the minimum required permission.

During the actual deployment, GigaVUE-FM provides a Permission Check tool that allows you to verify:

  • access to public cloud endpoints,
  • if the required permissions are in place.

Note:  This tool is not a replacement for pre-deployment planning and permissions establishment.

Identify or Create the Necessary Keypairs

GigaVUE Fabric Components support administrative SSH access via SSH key pairs. When deploying these components the name of an AWS stored SSH Key must be provided to provision the public key on each component. The associated private key may then be used for administrative access to these components. Refer to AWS Key Pair for more details.

Identify the UCT-V Deployment Details

The UCT-V is provided as a Debian (.deb), RedHat Package Manager (.rpm), and Microsoft Installer (msi) package files. The UCT-V deployment configuration requires knowledge of the OS network interface naming conventions such as eth0, ens5, enX0, etc.

Before deploying UCT-V:

  • Identify the VMs where UCT-V deployment is required.
  • Familiarize yourself with OS Network interface naming conventions.
  • Identify the deployment method.

Identify the UCT-C Deployment Details

GigaVUE Cloud Suite for AWS supports hybrid deployments where traffic visibility for VMs (EC2 instances) and Kubernetes cluster is simultaneously supported from the same GigaVUE-FM, Monitoring Domain and GigaVUE V Series Node. The UCT-C Tap and Controller pod components are deployed to provide traffic acquisition in Kubernetes clusters. This is currently supported only for EKS clusters with EC2 worker nodes. For the specific planning and requirements for UCT-C based deployments for Kubernetes, refer to Universal Cloud TAP - Container Deployment Guide.